Optical-reading code preparation device

ABSTRACT

An optical-reading code preparation device includes: a storage unit able to receive data to be coded, and parameter data including presentation data, an encoding unit, able to produce code data on the basis of data to be coded and of parameter data, an imaging unit, able to produce data defining an image plane on the basis of presentation data and/or of code data, a scheduler devised so as to, in response to the receipt of data to be coded and of parameter data comprising presentation data: call the encoding unit with the data to be coded and the parameter data received so as to produce associated code data, call the imaging unit with the associated code data, selectively with some at least of the presentation data, call the imaging unit, and prepare an optical-reading code.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. patent application Ser. No.14/238,974 filed on Feb. 14, 2014, which claims priority toInternational Patent Application Serial No. PCT/FR2012/000325, filed onAug. 2, 2012, which claims priority to French Patent Application SerialNo. 1102520, filed on Aug. 16, 2011, all of which are incorporated byreference herein.

BACKGROUND AND SUMMARY

The invention relates to the field of preparation of optical-readingcodes.

An optical-reading code is a symbology, i.e. a graphic representation ofa set of data. Various formats have been proposed to codify theproduction of an image that bijectively corresponds to input data. Forexample Datamatrix (ISO/IEC 16022), Maxicode (ISO/IEC 16023), QR-Code(ISO/IEC 18004), among others, are among such formats.

The output image is composed of a set of square-shaped black and whitedots called modules. These points define a flat file, also called amatrix, from which the original data can be recovered.

Optical-reading codes are very advantageous since they can store a largeamount of data on a limited area, and in a highly reproducible manner.Thus, many software applications are now available for phones (alsocalled “smart phones” or “Smartphones”) and tablets. These applicationsmake it possible to read optical-reading codes and to use the datacontained therein. To do this, these applications use the photographicoptical sensor (or video camera), and restore the information on thebasis of the image or sequence of images taken. This type of applicationmakes it possible to avoid optical character recognition (OCR), andenables for example to provide a link to a website or another link in amagazine or in a shopwindow, without the user having to enter theaddress or to make any other effort.

One of the main drawbacks associated with optical-reading codes is thatthey are unsightly. As a matter of fact, the algorithms corresponding tothe various formats produce black and white squares matrices that aremeaningless to the person watching same. For example, it is difficult toassociate graphic elements of the universe of the code publisher with agiven code.

Moreover, associating a graphic display—whether a drawing or aphotograph—with an optical-reading code is complex, and generally makesthe code illegible, or severely limits the amount of information it cancontain. For these reasons, every effort to customize optical-readingcodes have so far been rather trials and errors, through tests andfailures, until a functional and aesthetically pleasing enough code hasbeen obtained. In this context, no solution currently exists to producegraphically-customized optical-reading codes, still less such codes thatare adapted to be printed in lots, for example, in several thousands ofcopies of seemingly similar codes, but each containing variousinformation.

The invention improves the situation. To this end, the inventionprovides for an optical-reading code preparation device comprising:

-   -   a storage unit able to receive data to be coded, and parameter        data comprising presentation data,    -   an encoding unit able to produce code data on the basis of data        to be coded and parameter data,    -   an imaging unit able to produce data defining an image plane on        the basis of presentation data and/or code data,    -   a scheduler devised so as to, in response to the receipt of data        to be coded and of parameter data comprising presentation data:    -   call the encoding unit with the data to be coded and the        parameter data received so as to produce associated code data,    -   call the imaging unit with the associated code data, selectively        with some at least of the presentation data so as to produce        data regarding a bright information plane and/or data regarding        a dark information plane,    -   call the imaging unit with some of the designated presentation        data defining an image so as to produce data regarding a bright        information plane and/or data regarding a dark information        plane, and    -   prepare the code on the basis of an arrangement, in a        predetermined order, of the data regarding a bright information        plane, the data regarding a dark information plane, the data        regarding a bright image plane, and the data regarding a dark        image plane.

The invention also relates to a method for preparing an optical-readingcode, which comprises:

-   -   receiving data to be coded, and parameter data comprising        presentation data,    -   calculating code data on the basis of data to be coded and        parameter data,    -   producing data regarding a bright information plane and/or data        regarding a dark information plane on the basis of the code        data, and selectively on the basis of some at least of the        presentation data,    -   producing data regarding a bright image plane and/or data        regarding a dark image plane on the basis of some at least of        the presentation data defining an image, and    -   preparing the code on the basis of an arrangement, in a        predetermined order, of the data regarding a bright information        plane and/or the data regarding a dark information plane, and/or        the data regarding a bright image plane, and/or data regarding a        dark image plane.

BRIEF DESCRIPTION OF THE DRAWINGS

Other characteristics and advantages of the invention will become moreapparent when reading the following description, taken from examplesgiven for illustration and not restriction, from the drawings wherein:

FIG. 1 shows a diagram of a device according to the invention;

FIG. 2 shows a schematic diagram of the operation of the device of FIG.1;

FIG. 3 shows an algorithm for the preparation of optical-reading codesimplemented by the device of FIG. 1;

FIG. 4 shows an embodiment of a first operation of FIG. 3;

FIG. 5 shows a schematic diagram of a second operation of FIG. 3;

FIG. 6 shows a third operation of FIG. 3;

FIG. 7 shows an exemplary implementation of a fourth operation of FIG.3;

FIG. 8 shows an exemplary implementation of another embodiment; and

FIG. 9 shows an exemplary implementation of still another embodiment.

DETAILED DESCRIPTION

The drawings and the description below mainly contain characteristicelements. They can therefore be used not only for a better understandingof the present invention, but also to contribute to the definitionthereof, if need be. This description is likely to involve elements thatmay be protected by royalties and/or copyrights. The rights holder hasno objection to the identical reproduction of this patent document orthe description thereof, as it appears in the official records, byanyone. For the rest, he/she fully reserves his/her rights.

FIG. 1 shows a device according to the invention. As can be seen in thisFigure, the device 2 comprises a storage unit 4, an encoding unit 6, animaging unit 8 and a scheduler 10.

In the example described here, the storage unit 4 is a conventionalstorage medium, which may be a platter or flash memory hard disk (SSD),a flash or ROM memory, a physical storage medium such as a compact disk(CD), a DVD, a Blue-Ray disk, or any other type of physical storagemedium. The storage unit 4 may also be transferred to a system areanetwork (SAN) or to the Internet or generally to the “cloud.”

In the present example, the encoding unit 6, the imaging unit 8 and thescheduler 10 are software elements executed by a computer containingsame. However, they could be implemented in a distributed way onmultiple computers, or be in the form of printed circuits (ASIC, FPGA orany other one), or dedicated microprocessors (NoC or SoC). The scheduler10 selectively controls the encoding unit 6 and the imaging unit 8, andaccesses the storage unit 4 to implement the processing according to theinvention.

FIG. 2 shows the processing performed by the device 2. As can be seen inthis Figure, the device 2 receives on the one hand parameters data 20and on the other hand, data to be coded 22, and outputs a code 24.

The parameter data 20 consist of all the presentation data making itpossible to customize the optical-reading code to be produced, as wellas any parameter specific to the execution of the device 2. For example,the parameter data 20 may include, without limitation, code backgrounddata, code foreground data, image data, pattern data, patterntransformation data, or any other data. The execution-specificparameters may include data of the type of code to be produced, batchdata, block data, or any other data. The nature and the function ofthese data will be specified in the following.

The data to be coded 22 are the data the code 24 must contain. Thesedata may form a business card file, or a Web address, or any otherinformation defined by one or more text strings, bit strings or anyother string. Although the code 24 is shown in FIG. 2 in its final form,as it will be seen by a physical person, it should be understood thatthe code 24 produced by the device 2 may be any element enabling toobtain a functional optical-reading code. Thus, the code 24 may beavailable in the form of vector graphics, as a bitmap image, or still inthe form of a document wherein multiple layers are defined, but not yetmerged, and in any form of data which may be assembled to obtain suchelements.

FIG. 3 shows a diagram of an exemplary algorithm implemented by thedevice 2 to prepare an optical-reading code. This algorithm begins withan operation 300 wherein the parameter data 20 are entered by the user,either directly or by indicating the location of a source containingthese data. These data will condition the preparation of the code 24 andthe final rendering effect.

As already seen, such data may include code background data, codeforeground data, image data, pattern data, pattern transformation data,data of the type of code to be produced, batch data and block data. As amatter of fact, the applicant has identified several ways to graphicallycustomize an optical-reading code, through for example the addition of abackground or a foreground, or by using one or several patterns for theachievement of the modules.

The background data and the foreground data may include, for example, achosen colour background, in the form of a bitmap or a vector, or acontinuous-tone image. For a given code, only background data, orforeground data may be provided. As a matter of fact, the mostfrequently chosen colour to represent a “0” piece of information is thewhite colour, which comes to have a transparent background orforeground. However, if a background and a foreground are provided for,one of them has to be detected as “bright”, i.e. as a “0” piece ofinformation, and the other one has to be detected as “dark”, i.e. a “1”piece of information.

The image data may include any graphic type data in the form of a bitmapor a vector, which enables to reproduce one or more photographs, ordrawings associated with a company, such as a logo, a model, a brandmark or any other image. As will be seen later, the dimensions of theimage associated with the image data may be any dimensions, as comparedto the dimensions desired for the code 24, i.e. they may be smaller, thesame or larger.

Pattern data may include all graphic type data, in the form of a bitmapor a vector, which can be used to form patterns intended to representthe modules or groups of modules that make up the information in theoptical-reading code. The pattern transformation data may include anyfunction and parameter enabling to apply a geometric and/or opticaltransformation to a pattern. These transformations include, for example,rotation about an axis, translation, homothety, light projection,shadows projection, soft-focus, distortion, transparency, turbulence,etc., or a composition of such transformations.

Using pattern data and transformation data to form original patterns ispossible thanks to the intrinsic tolerance of information detection. Asa matter of fact, when an optical-reading code is decoded, it is firstdivided into a plurality of areas corresponding to each of the boxes inthe matrix. Then, each area is determined as dark or bright, whichdifferentiates a “1” piece of information and a “0” piece ofinformation. The result of this is that almost any graphic element canbe used to represent a module, insofar as this element has a colourprofile that will be properly decoded, and as this element occupies asufficient space in the concerned area.

For example, a red heart can be used to replace the black modules,insofar as such hearts cover a sufficient portion of each area. Thisprinciple similarly applies to the transformations described above. Theresult of the foregoing is that a pattern can also “go past” the areawhich it corresponds to, insofar as this pattern does not change theinformation of the area(s) beyond which it extends.

The concept of “bright” and “dark” discovered by the Applicant iscrucial. As a matter of fact, it has long been considered that, toreliably, i.e. without risking too many mistakes, produce a functionaloptical-reading code, the modules must be completely black to bedetected as a “1” piece of information and totally white to be detectedas a “0” piece of information. In addition, today it is also consideredas essential for the modules to be square-shaped, and identical to eachother within a given code. As a matter of fact, if these conditions arenot met, it becomes necessary to make several series of approximationsto obtain a functional code.

For example, the integration of an image, even a small one is madethrough trials and errors: the image is integrated, usually in themiddle of the code, and then the code is tested. This test is usuallynegative. Then the image is modified, often by trimming, and then theprocess is repeated, until a functional and more or less aesthetic codeis obtained.

The approach clearly results more from art than computer graphics. Andit is impossible to create a lot of media that have optical-readingcodes both customized for people, for example with their business cards,and graphically customized, for example with the logos of theircompanies.

The Applicant has discovered that these concepts are erroneous, and thatthe “bright” parts, and the “dark” parts should actually bedistinguished. As a matter of fact, the applicant has found that it ispossible to achieve the following equivalences:

-   -   a “bright” part will be detected as a “0” piece of information,        and    -   a “dark” part will be detected as a “1” piece of information. In        the following, “0” or “bright” data will therefore designate a        module carrying a “0” piece of information and “1” or “dark”        data will therefore designate a module carrying a “1” piece of        information.

This discovery is fundamental, and enabled the applicant to producecustomized optical-reading codes, wherein the graphic element used forrepresenting the modules is no longer limited to a black squareoccupying a space having given dimensions, but almost any graphicelement having appropriate properties. These optical-reading codes couldalso be customized by the free integration of graphic elements notlinked to the modules, such as images.

The data of the code 24 to be produced make it possible to specify thetype of the code 24 output as described above: bitmap image, vectordrawing, document including not smoothed layers, etc. Batch data make itpossible to indicate that several codes must be made using the sameparameters and different data to be coded 22. It thus becomes possibleto print media with customized information using the optical-readingcode, but with the same type of batch graphic customization.

In the case of batch processing, only the data to be inserted into thecode change, but the graphic customization data and the visual renderingremain the same. As discussed below, the invention enables to reliablyproduce a significant amount of similarly customized codes as regardsgraphics, and differently customized as regards the data, as well asreliably, i.e. without error or through tests and failures.

The block data enable to indicate the number of modules that arereserved around the code. Conventionally, the block data consist of twoor four modules containing a “bright” or “0” piece of information,around the information matrix, i.e. around the code.

Once the parameters are set, the algorithm continues in an operation 310with the creation of a background layer and a foreground layer. As amatter of fact, the applicant has found that it is possible to customizethe optical-reading code in an extremely rich and free way, insofar ascertain rules are followed. These rules mainly relate to preserving thedetection of the “bright” and “dark” information.

FIG. 4 shows an exemplary implementation of the operation 310. In anoperation 400, the foreground data, the background data and the imagedata associated with the code to be prepared are recovered.

Then, an operation 410 tests the presence of image data. As a matter offact, if these data are not available, then the background layer and theforeground layer are directly executed in an operation 420 using a Lay() function and the operation 310 ends in 430. If no background data orforeground data are available, the Lay( ) function does nothing, orreturns a transparent layer.

If image data have been combined, then a Split_I( ) function is executedin an operation 440. The Split_I( ) function receives the image data andthe background data as arguments. The Split_I( ) function will producetwo layers on the basis of the image data, depending on the type ofinformation associated with the background data. Thus, if the backgrounddata correspond to “dark” information, then the Split_I( ) functioncreates a Img_B layer which contains the image data corresponding to“dark” information, and a Img_F layer that contains the image datacorresponding to “bright” information.

An exemplary method for executing the Split_I( ) function consists intaking the image data, and cutting them according to the modules matrixto define a set of areas in the image data. Then, each area is tested todetermine if it contains the image data corresponding to “bright”information, or image data corresponding to “dark” information. Finally,the Img_B and Img_F layers are reconstructed on the basis of thisdetermination.

Finally, a BGL background layer is calculated using a Fus( ) function inan operation 450, a FGL foreground layer is calculated using the Fus( )function in an operation 460 and the operation ends in 430. The Fus( )function is executed by smoothing the planes that are passed asarguments in the order of submission. In the example described here, theImg_B layer is smoothed on the BG layer, and the Img_F layer is smoothedon the FG layer.

Once the background and foreground layers are produced, the preparationof the optical-reading code continues in a data matrices creationoperation 320. The operation 320 comprises two steps. In a first step,the data to be coded 22 are transformed into an information matrix inaccordance with the code format selected. Then, an additional matrix isgenerated, the role of which will be explained hereunder.

FIG. 5 shows a schematic diagram of implementation of the operation 320,where the information matrix is referenced 500 and the additional matrixis referenced 510. In this operation, if block data are defined, theyare integrated in the matrices, which are partially shown here.

It should be noted that although all the coefficients are shown in FIG.5, only those which are not null will be effectively discussed in thefollowing. The matrices 500 and 510 could also be represented in theform of a series of clues that indicate the locations of the non nullcoefficients, which are the locations in the code wherein the modulesshould be represented. The data representing the matrices 500 and 510are the code data. The example described here is suitable for theQR-Code format. Other code formats will induce different matrices.

Then, an optional operation 330 is executed. The operation 330 is agroup detection operation. As a matter of fact, it may be interesting tocombine several pieces of information of the “1” or “0” type which arecontiguous, depending on the pattern selected to form the code.

Thus, in one example implemented by the applicant, the patterns arepencil lines. When several lines are aligned vertically or horizontally,it may be interesting to combine these into one long continuous line.Similarly, when an image is used as a pattern, for example a hamburger,it may be interesting to combine identical pieces of information whichform a square to substitute a single image therefor, whereon homothetyis executed. Alternately, other forms, for example similar to Tetris(trademark) type elements shapes may be detected and used.

The operation 330 facilitates this implementation by detecting thesegroups in the matrices produced with the operation 320. FIG. 6 shows aschematic diagram of the implementation of the operation 330, where thematrix before detection is referenced 600 and the matrix after detectionis referenced 610. In the example described here, a single coefficientcomprising group detection information is substituted for a group ofcoefficients, and the other coefficients are nullified. As in FIG. 5,the matrices 600 and 610 are shown in parts, and in the matrix 600, arectangular block of 3*2 modules size has been identified. Otheralternative solutions may be implemented.

The group detection operation 330 is generally carried out on theinformation matrix 500, since the modules corresponding to “1”information are generally made with a “dark” colour. In the exampledescribed here, only the matrix 500 is the object of a detection group,and the matrix 510 remains unchanged. In alternative solutions, thematrix 510 or both matrices 500 and 510 could be the object of theoperation 330.

Then an operation 340 is performed, wherein the MUL useful informationlayer and a MCL additional information layer are generated. FIG. 7 showsan exemplary implementation of this operation. This operation starts in700 with the recovery of the BG background data, the Pat pattern dataand the Fx_Par transformation data. In the example described here, thePat pattern and the Fx_Par transformation data are tables.

Then a Chs( ) function is executed in a operation 710 to determine thematrix which will be used as a basis for the preparation of theinformation layer. As a matter of fact, if the BGL background layercorresponds to “bright” information, then this is the MU usefulinformation matrix. If not so, the MC additional information matrix isused.

The Chs( ) function therefore receives the MU useful information matrix,the MC additional information matrix (if need be as modified after theoperation 330), and the BGL background layer as arguments. The Chs( )function returns two matrices, MI and M2, the MI matrix comprising theMU matrix if the information of the BGL background layer are bright, andthe MC matrix if not so. In the absence of a background layer, or if thelayer is transparent, then the M1 matrix is the MU matrix.

Then, in an operation 720, the matrix M1 is transformed into aninformation plane by a Mak( ) function. At first, the Mak( ) functiontransforms the M1 matrix into a table in a MI_Tab( ) function. TheMI_Tab( ) function receives the MI matrix of the operation 710 and thePat pattern data and the Fx_Par transformation data as arguments, andreturns a MI_Tab[ ] table, wherein each element comprises one or moreindices of the MI matrix areas.

In the example described here, each element of the MI_Tab[ ] table is amatrix of identical dimensions to those of MI. In each MI_Tab[i] matrix,only some coefficients are not null and correspond to not nullcoefficients of MI. When a coefficient of a MI_Tab [i] matrix is notnull, it is null in all the other MI_Tab[j] matrices, and the sum of allthe MI_Tab[i] matrices gives MI.

Not null coefficients can be assigned in each MI_Tab[i] matrix in apredetermined order, or randomly, and can be performed according to thePat pattern data and the Fx_Par transformation data. In the latter case,this means that, when processing a batch, all the produced codes willhave a common visual form, but they will however be completely differentfrom each other. Each M1 module is therefore in a matrix of the MI_Tab[] table, and in one only.

This makes it possible to process all the information of the M1 matrixseparately using varied patterns and/or by applying different effectsfor each not null coefficient of MI. When the operation 330 isperformed, the selection of the pattern may depend on the groupdetection information, and more particularly on the size of the group itrefers to.

In a second step, the Mak( ) function generates the MUL usefulinformation layer on the basis of the MI_Tab[ ] table, and of the Patpattern data and the Fx_Par transformation data to represent the moduleswith the elements identified by the Pat pattern data according to theFx_Par transformation data, at the locations designated by the not nullcoefficients of the MI_Tab[i] matrices.

In the example described herein, the Fx_Par transformation data are soapplied that the baric centre of the Pat pattern data is preserved. Thisensures that the pattern data prior to the application of the FxPartransformation data and the Pat pattern data after the application ofthe Fx_Par transformation data will be detected in the same way by thecode reading application.

In the simplest implementation, there is only one type of pattern and notransformation. In this case, the MI_Tab[ ] table contains a uniquematrix identical to the M1 matrix, and the modules are shown at thelocations indicated by the M1 matrix with the pattern data.

Then a MCL additional information layer is created similarly in anoperation 730 by the Mak(M2) function, and the operation 340 ends in740. Alternately, the operations 720 and 730 might not return layers,but layers declarations data, if a declarative graphics engine is used.

Once all the background, foreground, and information layers have beencreated, the operation 350 processes these to provide the code 24 asprovided in the data type of data. Thus, if these data indicate that acode 24 in the form of a smoothed image is requested, then thisoperation smoothes the background layer, the useful information layer,the foreground layer, and the additional information layer. If a notsmoothed image is requested, then these layers are provided directlyetc. Then again, the code 24 may be defined by a set of layersdeclarations data if a declarative graphics engine is used.

In addition, some of the operations described above may be optional orperformed in a different order to get a better visual effect. Forexample, as regards the additional information, such information isoften desired to be invisible, i.e. transparent. More specifically,additional information have to be displayed only when corresponds to a“bright” piece of information that is located in a code area wherein abackground or a “dark” foreground has been applied. When such areas donot exist, the application of the additional information layer may beomitted.

This is reinforced by the fact that background data more often existthan foreground data. As a result, the FGL foreground layer is oftenreduced to the Img_F part of the image, which reduces the chance forsuch areas to exist.

In addition it can be noted from the above that it is easy tomass-produce highly customized optical-reading codes thanks to theinvention. As a matter of fact, as the production of the code providesfor the preservation of the “bright” and “dark” information, whateverthe graphic customization considered, it is certain that the codesproduced within the scope of the invention are functional. This is veryadvantageous, and not possible in the state of the art.

The applicant has also discovered another advantageous way to produce anoptical-reading code. FIG. 8 shows a first embodiment thereof. In anoperation 800, the image data, the pattern data, the transformationdata, and the data of the MU and MC matrices are received.

Then, in an operation 810, a LE( ) function is applied to the imagedata. The LE( ) function aims at changing the Img image represented bythe image data, by making it progressively transparent. As a result,Low_Img data are obtained, which represent an image wherein all the dataof the original image, the brightness of which corresponds to a “bright”piece of information, have been removed by making these progressivelytransparent. Alternately, this function could make all the elements ofthe input image, the brightness of which is lower than a selectedthreshold, transparent, and all the elements of the input images, thebrightness of which is greater than the selected threshold, opaque.

Then, in an operation 820, the MU_Img and MC_Img data are calculated bythe Mak(MU, MC) function, then the MU_Img data are made black in anoperation 830 by a Blk( ) function. The Blk( ) function transforms allthe elements of the MU_Img image that are not strictly white into blackelements, to provide data defining a MU_Img_Blk image. Thereafter, theMU_Img_Blk data are superimposed on the Low_Img data in an operation840, then a colour inversion operation is performed in an operation 850by a Inv( ) function to produce Holed_Inv data. The Holed_Inv data thuscontain the colorimetric mirror of the Img image data with transparentholes corresponding to the locations of the “dark” modules of the MUmatrix.

In an operation 860, the LE( ) function is applied to the Holed_Invdata, and the resulting High_Holed_Inv data are reversed again by theInv( ) function in an operation 870 to produce High_Holed data. Inpractice, the High_Holed data correspond to the “dark” parts of the Imgimage wherein the modules corresponding to the “bright” information havebeen represented. Finally, in an operation 880, the MU_Img, Low_Img,MC_Img and High_Holed data layers are smoothed to produce the code 24.As described above, these operations can generate a code 24 in the formof a smoothed image, in the form of a group of ordered layers, or in theform of a set of layers declarations if a declarative graphics engine isused.

FIG. 9 shows a variant of FIG. 8. In an operation 900, the image data,the pattern data, the transformation data, and the MU and MC matricesdata are received. At first, this variant aims at calculating the partsof the Img image which are “dark” and which correspond to the locationsof “dark” modules in the MU matrix. To do this, in an operation 905, theMU_Img data are calculated by the Mak(MU) function, then the MU_Img dataare made black in an operation 907 by the Blk( ) function to providedata defining a MU_Img_Blk image.

Then the Inv( ) function is applied to the MU_Img_Blk data in anoperation 910 to obtain MU_Img_Inv data. Typically, the MU_Img_Inv imagecorresponds to the MC matrix with the block data if any, wherein the“bright” modules are shown in black, and wherein the “dark” modules areshown in white. The LE( ) function is then applied to the MU_Img_Invdata in an operation 915, to make the “bright” modules opaque and the“dark” modules transparent. The resulting data are calledLow_MU_Img_Inv.

In an operation 920, the image data of the Img image arecolorimetrically reversed by the Inv( ) function to get Img_Inv data andthen the Low_MU_Img_Inv data are merged with the Img_Inv data in anoperation 925. As a result, Img_Msk_Inv mask data are obtained, whichcontain the colorimetric mirror of the parts of the Img image whichcorrespond to the “dark” modules of MU. To obtain an image thatcomprises the parts of the Img image which are “dark” and whichcorrespond to the locations of “dark” modules in the MU matrix, the Inv() function is applied to the Img_Msk_Inv data in an operation 930, thenthe LE( ) function is applied to the resulting Img_Msk data in anoperation 935, which results in Low_Img_Msk output data.

In a second step, this variant aims at calculating the parts of the Imgimage which are “bright” and which correspond to locations of “dark”modules in the MU matrix. To do this, in an operation 940, the MC_Imgdata are calculated by the Mak(MC) function, then the MC_Img data aremade white in an operation 945 by a Wht( ) function. The Wht( ) functiontransforms all the elements of the MC_Img image that are not strictlyblack into white elements, to provide data defining a MC_Img_Wht image.

Then the LE( ) function is applied to the MC_Img_Wht data in anoperation 947 to obtain High_MC_Img data corresponding to an image,wherein the “dark” modules of MU are opaque, and the “bright” modules ofMC are transparent. Then, in an operation 950, the High_MC_Img data aremerged with the image data of the Img image to obtain Img_Msk data.

The Img_Msk data contain the parts of the Img image that correspond tothe “bright” modules of MC. To obtain an image which comprises the partsof the Img image which are “bright” and which correspond to locations of“bright” modules of the MC matrix, the Inv( ) function is applied to theImg_Msk data in an operation 955, then the LE( ) function is applied tothe resulting Img_Msk_Inv data in an operation 960, and the Invfunction( ) is applied again in an operation 965, which results inHigh_Img_Msk output data. Specifically, the Low_Img_Msk data contain allthe “dark” data of the Img image, as masked by the image representingthe “dark” modules of the MU matrix, and the High_Img_Msk data containall the “bright” data of the Img image, as masked by the image of the“bright” modules of the MC matrix.

To get the code 24, then the planes simply have to be superimposed in anoperation 970, from the deepest to the foremost one:

-   -   MU_Img data,    -   Low_Img_Msk data,    -   MC_Img data and    -   High_Img_Msk data.

Alternately, the image data of the Img image can be used as thebackground for the code 24 thus produced. As a matter of fact, it hasbeen seen that the modules need not occupy the entire space provided inthe code, without affecting the quality of the code 24 produced.

Thus, the applicant has found that, within the scope of the productionof codes with a fairly large image as a graphic customization, it isadvantageous and aesthetic to use modules, the size of which is slightlysmaller than the location reserved for them in the code 24. As a matterof fact, with modules that do not occupy the whole location, “notcontiguous” modules are obtained, which is visually shown by a gapbetween the rows and columns of modules, which gives a very good visualrendering.

However, as has just been seen, the variant of FIG. 9 precisely cuts theimage along the contours of the modules, so that they fill the locationsdedicated to them. Therefore, the superposition of the planes describedabove then leaves the gaps empty. Reusing the Img image as a backgroundfills these gaps without corrupting the code 24, and even improves thevisual rendering thereof.

Again, the code 24 may be provided as specified in the code type data.Thus, if these data indicate that a code 24 in the form of a smoothedimage is requested, then this operation smoothes the planes in the orderdefined above. If a non-smoothed image is requested, then these layersare provided directly etc. Again, the code 24 may be defined by a set oflayers declarations if a declarative graphics engine is used.

In the foregoing, smoothing and mergers were alternately referred to.These operations aim as much at a conventional smoothing of the planes,as at the merger with alpha channel management, as appropriate. Inaddition, in many cases, the operations are performed to producedisjoint, i.e. not overlapping, graphic elements. In this case, usingsmoothing or a merger with alpha channel management is indifferent. Thisis for example the case with some of the data of the variant of FIG. 9:the Low_Img_Msk and High_Img_Msk data are completely separate.

The use of planes transparency and separation explains the maindifference between the variant of FIG. 8 and the variant of FIG. 9:

In FIG. 8, the processing focuses on the Img image, and the darkportions of the Img image which must be “drilled” with “bright” modulesare desired to be preserved. Using the LE( ) function makes sense sincethe separation in “bright” and “dark” layers is complementary, andreconstructs the Img image when planes are merged. Using other toolsthan the LE( ) function in this variant might give different results notpreserving the Img image in the code 24;

In FIG. 9, the processing focuses on the code useful piece ofinformation, and the Img image is methodically cut according to the“bright” and “dark” modules. Here, the LE( ) function could easily bereplaced without any consequence for the integrity of the Img image inthe final code 24.

Moreover, if image data are provided, background or foreground data arerarely provided, which still brings these embodiments closer. In anyevent, the foreground and background data can be processed as image datain the variants of FIGS. 8 and 9.

In addition, all the variants and options described in connection withFIGS. 1-7 can be directly applied to the variants of FIGS. 8 and 9,including those concerning the group detection, the use of variouspatterns for the modules and the application of transformations. Themain difference in these embodiments is that the embodiment of FIGS. 1-7handles the images in a different way, and relies more on layersmoothing, where the variants of FIGS. 8 and 9 make use of transparency.

Additional variations may also be applied to improve the visualrendering of all the variants described. As a matter of fact, theapplicant has found that it may be advantageous to re-apply all or partof the background, the foreground or the image as the foreground on thecode prepared according to the invention, with a low opacity, usuallylower than 75%. This allows homogenizing the display of the image,without changing the additional information.

Moreover, most optical-reading codes have specific areas which containinformation defined by the format and never varying. These areas areusually called a “driver”. Their function is to enable an applicationtrying to decode the optical-reading code to place it according to apredefined orientation, in order to read it in the correct order,whatever the orientation in which the code has been photographed.

For example, in the basic QR-code type codes, three areas are providedin the top left, top right and bottom left corners, which include afirst square of “dark” information, a second square of “bright”information within the first square, and a square full of “dark”information within the second square. These drivers are shown in FIG. 2,for example. A final driver is also included at the bottom right.

In some optical-reading code formats, these drivers are crucial because,without them, reading the code correctly is impossible. It may bedesired, for safety reasons, not to treat the drivers like the rest ofthe code data. This can be done within the scope of the invention byseparating the drivers in the operation 710, as is done for theinformation matrix. Then, the drivers are smoothed according to theircorrespondence with a dark or not information.

Furthermore, the combinations and smoothing described above are providedto give an optimum visual rendering for the code 24. However, other lessvisually optimal solutions can be used, for example by reversing somesmoothing.

The result of the above is that the preparation of the code is based onalternating layers of the graphic type and information layers that areassociated with opposite information. For example, a bright backgroundis used, whereon dark information, then a dark foreground and brightadditional information, etc. are smoothed. The smoothing, pattern andeffects variations are free, insofar as this smoothing preservesinformation.

This preservation of information enables to produce an almost infiniterange of graphic customizations, something that has been inconceivableso far. In addition, the invention guarantees the integrity of the codeand of the images, and no verification or editing step is required.

Finally, as the invention is compatible with any image, whatever thesize thereof, it becomes very easy to integrate an optical-reading codeinto any graphic support, such as a poster or an advertisement. Therelative position of the image forming the medium simply has to bespecified and this image will be modified by integrating the code. Thus,you no longer have on the one hand a visual medium and on the other handa code added to this medium, but an actual merging of the code and themedium wherein it is to be integrated. The invention is of coursecompatible with not two-dimension optical-reading codes, such as EAN-8,EAN-13, UPC-A, UPC-E, PDF-417 or other codes.

What is claimed is:
 1. A two-dimension image comprising a firsttwo-dimension layer comprising a transformation of a part of an encodedinformation, a code to encode and decode said information being anoptical code; wherein the transformation is one of an opticaltransformation and a geometrical transformation of the part of theencoded information.
 2. The two-dimension image of claim 1, wherein thetransformation comprises a vector operation.
 3. The two-dimension imageof claim 1, wherein the optical code is compliant with an encoding anddecoding standard.
 4. The two-dimension image of claim 3, wherein theencoding and decoding standard is one of a QR standard, an EAN standardand a Datamatrix standard.
 5. The two-dimension image of claim 1,wherein the optical code encodes at least one of an URL, an URI and analphanumeric information.
 6. The two-dimension image of claim 1, whereinthe geometrical transformation is one of a rotation about an axis, atranslation and a scaling.
 7. The two-dimension image of claim 1,wherein the optical transformation is one of an illumination, adarkening, a flouting, a shading and a shaking.
 8. The two-dimensionassembly of claim 1, further including reserved areas around subparts ofthe transformation of the information.
 9. The two-dimension image ofclaim 1, further comprising a second two-dimension layer comprising apictorial image which is one of an overlay and an underlay of the firsttwo-dimension layer.
 10. The two-dimension image of claim 9, wherein thepictorial image comprises one of a photo, a trade dress and a trademark.11. The two-dimension image of claim 9, wherein portions of thepictorial image are visible in between portions of transformations ofparts of the encoded information.
 12. The two-dimension image of claim9, wherein the first layer is divided into a first portion with lightshades and a second portion with dark shades, the second layer isdivided into a first portion with light shades and a second portion withdark shades, the first portion of the first layer is one of an overlayand an underlay of one of the first portion and the second portion ofthe second layer and the second portion of the first layer is one of anoverlay and an underlay of one of the first portion and the secondportion of the second layer.
 13. The two-dimension image of claim 12,wherein the first portion and the second portion of the second layerhave been produced by an inversion of brightness features of an originalsecond layer.
 14. The two-dimension image of claim 1, which is generatedby a computer process from a source file stored on a non-transitorycomputer media, said source file comprising: information to be encodedusing an optical code; at least a parameter defining at least one of anoptical and a geometrical transformation of said information.
 15. Thetwo-dimension image of claim 14, wherein the source file furthercomprises a pictorial image.
 16. A source file stored on anon-transitory computer media, said source file comprising: informationto be encoded using an optical code, said optical code being usable todecode the information; at least a parameter defining at least one of anoptical and a geometrical transformation of said information.
 17. Thesource file of claim 16, wherein the optical code is compliant with anencoding and decoding standard.
 18. The source file of claim 17, furthercomprising a pictorial image.
 19. The source file of claim 18, whereinthe pictorial image is divided into a first portion with light shadesand a second portion with dark shades.